-9- 



REMARKS 

The Examiner has rejected Claims 1, 7, 9-1 1, 17, 19-23, and 25-32 under 35 
US.C 1 02(e) as being anticipated by Muret et at. (U.S. Patent No.6,792,458). Applicant 
respectfully disagrees with such rejection. 

With respect to independent Claims 1,11 and 21, the Examiner has relied on Col. 
1 , line 65; Col. 4, lines 40-65; Col. 5, lines 61-65; Col. 19, lines 27-39; and Figure 17 in 
Muret to make a prior art showing of applicant's claimed "identifying a plurality of 
templates provided based on user input." 

Applicant respectfully notes that the above excerpts relied on by the Examiner 
merely disclose that "reports are delivered upon request" (Col. 1, line 65), in addition to 
disclosing that a "log engine 200 efficiently reads each line in each of the log files 510 
and separates each line into its individual parts," where "Visitor Centric Data Modeling 
keeps [traffic] data associated with the visitor that generated it" (Col. 4, lines 40-49). 
Further, the excerpts disclose that "[a] user 530 sends a report request 540 to the report 
engine 400 via a web server 520," where "[t]he report engine 400 obtains the data 
required to generate the report from the database 300, generates the report, and delivers 
the generated report 550 to the user 530 via the web server 520" (Col, 5, lines 62-67). 
Further still, the excerpts disclose that "[u]ser requests for reports are generated and 
passed to the report engine 400 from the web server 520," where "[t]he passing of 
parameters 1500 is built into the navigation of the reporting interface" (Col, 19, lines 30- 
36). 

However, merely sending a report request to a report engine, where the report 
engine obtains data required to generate the report from a database, generates the report, 
and delivers the generated report to a user, as in Muret, fails to even suggest " identifying 
a plurality of templates provided based on user input " (emphasis added), as claimed by 
applicant. Nowhere in the above excerpts is "a plurality of templates provided based on 
user input " identified (emphasis added), as specifically claimed by applicant. 
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Also with respect to independent Claims 1,11 and 21, the Examiner has relied on 
Col. 2, lines 16-50; Col. 5, lines 17-55 and 64; Col. 13, lines 36-60; Col. 14, lines 57-61; 
Col. 15, lines 51-61; Col 18, lines 10-26; Col. 19, lines 10-12; and Figures 8, 10, 12, and 
15 in Muret to make a prior art showing of applicant's claimed "querying a database for 
network traffic information based on the identified templates" (see this or similar, but not 
necessarily identical language in the foregoing independent claims). 

Applicant respectfully notes that the above excerpts relied on by the Examiner 
merely disclose "producing] reports showing detailed 'return on investment' 
information," where "a report engine.. . generates reports based on the processed data 
stored in the relational database" (Col. 2, lines 1 1-22). Additionally, the excerpts 
disclose that "database 300 is relational and centers the data in the visitor table 310, 
creating a Visitor Centric Data Model" where "each of [existing] data tables 315 store 
different visitor parameters such as domain, browser, and referral" (Col. 5, lines 18-29). 
Further, the excerpts disclose that "report engine 400 obtains the data required to generate 
the report from the database 300, generates the report, and delivers the generated report 
550 to the user 530" (Col. 5, lines 64-66). Further still, the excerpts disclose a "DNS 
resolver module 260," where "[f]or each IP number that needs resolving, a query is sent 
out to the Internet, where it bounces around a few times in the DNS system before 
coming back with the answer" (Col. 13, lines 40-46), 

Also, the excerpts disclose that "it is desirable to send queries 1 1 30 as rapidly as 
possible" (Col. 14, lines 59-60), and that when "[a]n unresolved IP number 1 180 enters 
the DNS resolver module 260... [t]he DNS resolver module 260 will make multiple 
attempts at resolving the IP number by sending out multiple queries 1 1 30 one at a time 
using different query information" (Col. 15, lines 53-57). In addition, the excerpts 
disclose that "database 300 contains a visitor table 3 10 and data tables 315" as well as 
"methods module 1410 that provides an interface for accessing, seeking, and inserting 
data into the visitor and data tables 310 and 315" (Col. 18, lines 12-17). Furthermore, the 
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excerpts disclose that "access and delivery of reports is preferably controlled using a 
Javascript application" (Col. 19, lines 9-10). 

However, merely generating reports based on processed data stored in a relational 
database, where a report engine obtains data required to generate the report from the 
database, in addition to resolving IP numbers, and providing an interface for accessing, 
seeking, and inserting data into visitor and data tables, as in Muret, does not even suggest 
"querying a database for network traffic information based on the identified templates " 
(emphasis added), as claimed by applicant. Nowhere in the above excerpts is a database 
"quer[ied]... for network traffic information based on the identified templates " (emphasis 
added), as specifically claimed by applicant. 

Further, with respect to the independent claims, the Examiner has relied on Col, 
19, lines 1-15 and 29-55; Col. 21, lines 1-35; and Col. 26, lines 34-67 in Muret to make a 
prior art showing of applicant's claimed technique "wherein the templates are generated 
based on a plurality of user-configured parameters including network portions to be 
reported, a format of the reporting, a time or period, where the network traffic 
information comes from, what type of network traffic information is used, and to what 
location the network traffic information is written." 

Applicant respectfully notes that the above excerpts relied on by the Examiner 
merely disclose that "[t]he use of templates and dictionaries in the template module 
allows for easy customization of the reporting format," where "[templates can be used to 
change branding and the overall look and feel of the report interface" (Col. 19, lines 1-5). 
Additionally, the excerpts disclose that "[u]ser requests for reports are generated and 
passed to the report engine 400 from the web server 520," that "[t]he passing of 
parameters 1 500 is built into the navigation of the reporting interface," and that "[t]he 
parameters 1500 preferably contain three parts... [t]he session-id 1510... [t]he 
application data 1520 containing] the report-specific parameters used to select the 
correct report. . . [and] [t]he user session info " where "the read input step. . . parses the list 
of parameters 1 500 and separates the data into 'name-value pairs'. . . [and c]ontrol then 
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passes to the identify variables step 1550, which uses a pre-determined configuration 
1560 to match the external name-value pairs with internal variables (Col. 19, lines 30- 
52). 

Further, the excerpts disclose that "[a]s the end-user wants to see a different 
attribute of the report or data, they can click on navigational and control elements in 
either the navigation frame 1 870 or the report frame" (Col. 2 1 , lines 6-9), and that "[t]he 
user interface 4000 preferably includes a navigation area 4040 that contains a collection 
of menus that group the available reports into different categories" (Col. 26, lines 56-58). 

However, merely disclosing the use of templates and dictionaries for easy 
customization of a reporting format, in addition to disclosing that user requests for reports 
are passed to a report engine, and that passed parameters such as a session-id, application 
data containing report-specific parameters, and user session info are parsed, as in Muret, 
fails to disclose that "templates are generated based on a plurality of user-configured 
parameters including network portions to be reported , a format of the reporting , a time or 
period , where the network traffic information comes from , what type of network traffic 
information is used , and to what location the network traffic information is written" 
(emphasis added), as specifically claimed by applicant. 

Further still, with respect to independent Claim 22, the Examiner has relied on 
Col. 20, lines 31-67; and Figure 20 in Muret to make a prior art showing of applicant's 
claimed "determining whether a network analysis reporting system is operating in a 
report mode or edit mode." 

Applicant respectfully notes that the above excerpt relied on by the Examiner 
merely discloses "a flowchart of a preferred control routine for [a] format output 
module," where "templates and dictionaries are obtained from the template/dictionary 
module," and where "the requested report is formatted by merging the data stored in the 
buffer by the data query module 1440 with the chosen templates and dictionaries" (Col. 
20, lines 31-38). 
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However, merely obtaining templates and dictionaries from a template/dictionary 
module, and formatting a requested report by merging stored data with the chosen 
templates and dictionaries, as in Muret, fails to even suggest " determining whether a 
network analysis reporting system is operating in a report mode or edit mode " (emphasis 
added), as specifically claimed by applicant. 

In addition, with respect to independent Claim 22, the Examiner has relied on Cot. 
2 1 , lines 5- 1 5 and 55-60 in Muret to make a prior art showing of applicant's claimed "if 
the network analysis reporting system is operating in the edit mode, creating a plurality of 
templates based on user input." 

Applicant respectfully notes that the above excerpts relied on by the Examiner 
merely disclose that "[a]s the end-user wants to see a different attribute of the report or 
data, they can click on navigational and control elements in either the navigation frame 
1 870 or the report frame 1 880" (Col. 2 1 , lines 6-9), and that "[s]ince. . . the report engine 
400 creates reports when they are requested, all reports can display up-to-date real-time 
information" (Col. 21, lines 33-35). 

However, merely clicking on control elements to see a different attribute, in 
addition to displaying up-to-date real-time information by creating reports when they are 
requested, as in Muret, does not even suggest "if the network analysis reporting system is 
operating in the edit mode , creating a plurality of templates based on user input" 
(emphasis added), as specifically claimed by applicant. 

Also, with respect to independent Claim 23, the Examiner has relied on Col. 20, 
lines 1 1-29 and 3 1-67; and Figure 20 in Muret to make a prior art showing of applicant's 
claimed "determining whether the interface is operating in a report mode or edit mode." 

Applicant again notes that the excerpts from Muret relied on by the Examiner 
merely disclose obtaining templates and dictionaries from a template/dictionary module, 
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and formatting a requested report by merging stored data with the chosen templates and 
dictionaries, which fails to even suggest "determining whether the interface is operating 
in a report mode or edit mode " (emphasis added), as specifically claimed by applicant. 

In addition, with respect to independent Claim 23, the Examiner has relied on Col. 
20, lines 45-60 and 65-67 in Muret to make a prior art showing of applicant's claimed u if 
the interface is operating in the edit mode: (i) receiving input from a user, (ii) generating 
a parameter file based on the input, (iii) validating the parameter file, and (iv) storing the 
parameter file/' 

Applicant respectfully points out that the above excerpts relied on by the 
Examiner merely disclose that a "report engine 400 preferably uses a Javascript system 
comprising a special combination of HTML and Javascript to produce interactive reports 
that are extremely efficient and easy to use," where a [o]nce loaded, the web server 520 
only needs to deliver data to the web browser, which is then rendered on the user side of 
the Javascript system" (Col. 20, lines 45-53). Additionally, the excerpts disclose that 
4t [w]hen the end-user first accesses the report engine 400, the report request is sent to the 
web server 520 which returns the frameset/application 1830 and icons 1840" (Col. 21, 
lines 65-67). 

However, merely disclosing a web server that delivers data to a web browser, 
where the data is then rendered, as in Muret, fails to even suggest " if the interface is 
operating in the edit mode : (i) receiving input from a user, (ii) generating a parameter file 
based on the input , (iii) validating the parameter file , and (iv) storing the parameter file " 
(emphasis added), as specifically claimed by applicant 

Moreover, with respect to independent Claim 23, the Examiner has relied on Col. 
1 8, lines 45-57 in Muret to make a prior an showing of applicant's claimed "identifying 
templates in the parameter file." 
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Applicant respectfully notes that the above excerpt relied on by the Examiner 
merely discloses that "a report request 540 received by the web server 520 from an end- 
user is sent by the web server 520 to the report engine," where "[t]he session parser 
module 1420 reads the input from the report request 540 and sets internal variables 
accordingly" (Col. 18, lines 49-57). 

However, merely reading input from a report request and setting internal variables 
accordingly, as in Muret, fails to teach "identifying templates in the parameter file " 
(emphasis added), as specifically claimed by applicant. 

Still yet, with respect to independent Claim 23, the Examiner has relied on Col. 
25, lines 24-67 from Muret to make a prior art showing of applicant's claimed "retrieving 
templates of a second type from a second module." 

Applicant respectfully notes that the above excerpt relied on by the Examiner 
merely discloses that "the system 100 performs a special correlation between the e- 
commerce transaction data in the e-commerce log file 580 and normal website visitor 
traffic data in the standard log files 510" (Col. 25, lines 24-27), which fails to even 
suggest "retriev ing templates of a second type from a second module " (emphasis added), 
as claimed by applicant. 

The Examiner is reminded that a claim is anticipated only if each and every 
element as set forth in the claim is found, either expressly or inherently described in a 
single prior art reference. Verdegaal Bros. v. Union Oil Co. Of California, 814 F.2d 628, 
631, 2 USPQ2d 1051, 1053 (Fed. Cir. 1987). Moreover, the identical invention must be 
shown in as complete detail as contained in the claim. Richardson v. Suzuki Motor 
Co.m F.2d 1226, 1236, 9USPQ2d 1913, 1920 (Fed. Cir. 1989). The elements must be 
arranged as required by the claim. 

This criterion has simply not been met by the Muret reference, as noted above. 
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Applicant further notes that the prior art is also deficient with respect to the 
dependent claims. For example, with respect to Claim 10 et al, the Examiner has relied 
on Col. 25, lines 24-67 from the Muret reference to make a prior art showing of 
applicant's claimed technique "wherein the templates of the second type are populated 
with the network traffic information utilizing a second module." 

Applicant respectfully notes that the above excerpt relied on by the Examiner 
merely discloses that "the system 100 performs a special correlation between the e- 
commerce transaction data in the e-commerce log file 580 and normal website visitor 
traffic data in the standard log files 510" (Col. 25, lines 24-27), which fails to even 
.suggest a technique "wherein the templates of the second type are populated with the 
network traffic information utilizing a second module " (emphasis added), as claimed by 
applicant. 

Additionally, with respect to Claim 30, the Examiner has relied on Col. 19, lines 
30-45 and Col. 20, lines 14-61 from the Muret reference to make a prior art showing of 
applicant's claimed technique "wherein the templates specify a manner in which the 
network traffic information is extracted from the database and a manner in which the 
network traffic information is reported." 

Applicant respectfully notes that the above excerpts relied on by the Examiner 
merely disclose that "[u]ser requests for reports are generated and passed to the report 
engine 400 from the web server 520," where "[t]he passing of parameters 1 500 is built 
into the navigation of the reporting interface" (Col. 19, lines 30-36). Additionally, the 
excerpts disclose "a flowchart of a preferred control routine for [a] format output 
module," where "templates and dictionaries are obtained from the template/dictionary 
module," and where "the requested report is formatted by merging the data stored in the 
buffer by the data query module 1440 with the chosen templates and dictionaries" (CoK 
20, lines 3 1-38). 
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However, merely disclosing that user requests for reports are passed to a report 
engine, in addition to disclosing that templates and dictionaries are obtained from a 
template/dictionary module, where a requested report is formatted by merging stored data 
with the chosen template and dictionary, as in Muret, fails to disclose a technique 
"wherein the templates specify a manner in which the network traffic information is 
extracted from the database and a manner in which the network traffic information is 
reported" (emphasis added), as specifically claimed by applicant. 

Again, the foregoing anticipation criterion has simply not been met by the above 
reference, as noted above. 

Thus, a notice of allowance or specific prior art showing of each of the foregoing 
claim elements, in combination with the remaining claimed features, is respectfully 
requested. 

Still yet, applicant brings to the Examiner's attention the subject matter of new 
Claims 33-34 below, which are added for full consideration: 

"wherein another interface allows a user to select the user-configured 
parameters" (see Claim 33); and 

"wherein the time or period includes a time or period at which various 
template fields are populated" (see Claim 34). 

Thus, all of the independent claims are deemed allowable. Moreover, the 
remaining dependent claims are further deemed allowable, in view of their dependence 
on such independent claims. 

In the event a telephone conversation would expedite the prosecution of this 
application, the Examiner may reach the undersigned at (408) 505-5100. The 
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Commissioner is authorized to charge any additional fees or credit any overpayment to 
Deposit Account No. 50-1351 (Order No. NAI1P067). 
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